home *** CD-ROM | disk | FTP | other *** search
- From: error@stack.urc.tue.nl (Erlend Nagel)
- Subject: Re: Proposal
- Date: Wed, 1 Jun 1994 10:06:15 +0200 (MET DST)
- In-Reply-To: <H.ekK.D9IxnaYtw3o@elfhaven.ersys.edmonton.ab.ca> from "Michel Forget" at May 22, 94 01:33:14 am
- Mime-Version: 1.0
- Precedence: bulk
-
- Michel writes:
-
- > [> CTRL F - Find
- > [> CTRL G - Find next
- > [> CTRL R - Replace *1
- > [> CTRL T - Replace Next
- >
- > What about "Find Previous" or "Replace Previous"? In MasterBrowse,
- > I use ^E for "Find Previous" mainly because EFG = Previous/Find/Next
- > so it is easy to remember.
- >
- > Perhaps a better way to do "Find Previous" and "Find Next" would be
- > to set ^E (for ERT) as "Replace Previous" and ^D (for DFG) as
- > "Find Previous". Comments?
-
- I don't like it that almost any key has been given away already. That is
- one reason I want to see fewer short-cuts in the proposal. Another
- reason is that a program that wants to support all these short-cuts in
- menus will have LARGE menus. Anyway, what I think is a better solution
- is to have a backward/forward radiobuttonblock in the CTRL F (find)
- dialog. That way one can save some menu space and keyboardshortcuts.
-
- > How about ^L for "light" text in word processors.
-
- I don't like 'light'. I think this has to do with the weight of a
- typeface but in most wordprocessors it is this silly VDI rastered
- typeface (so a lighter colour). Because the notion of a 'light' typeface
- is a bit vague (because some fonts come in light, very light, normal,
- fat, extra fat etc.) I would like to leave this out of the proposal.
-
- > This seems to imply that programs should allow the setting of a block
- > with the keyboard. Or did you mean "goto block start" and "goto block
- > end"?
-
- As with all these short-cuts, I think that these are merely guidelines,
- which you use should you provide a function, so there is nu MUST provide
- for this function I think.
-
- > This is good as far as it goes, but I think it needs more work. Such
- > as, what gadgets should a windowed dialog box have? (I personally
- > use the MOVER|CLOSER set.) Also, it would be nice if we decided which
-
- Agreed, I think we do need some standard here too. Maybe we should
- suggest that the minimizer is only for non-modal dialogs, and that
- dialogs never have the fuller and scroll-bar. I really dislike some
- programs that were written with 640*480 in mind, that give me scrollbars
- to move through the dialog on my 640*400 screen. Maybe it would be a
- good recommendation to limit dialogs to 320 pixels in the vertical
- direction.
-
- > keypresses should be used. For example, EGEM has a very full set of
- > dialog commands that allows access to the clipboard, a history buffer,
- > moving to the first editable field, the last editable field, etc.
- > We should standardize this (if we can) while we are doing the ohter
- > keyboard shortcuts.
-
- I like the idea of moving to first and last field. Maybe we can use the
- same keys here as Atari prescribed for cursor movement, like shift
- downarrow for last field and shift uparrow for first field. BTW what is
- EGEM? Is it a library? Is it available as source, and can it be compiled
- with Sozobon C? (a private reply will do fine, not everyone may be
- interested).
-
- > [> ALT Z Font selector
- >
- > Atari says never to use Alternate in a menu shortcut. How about ^Z?
-
- Agreed. And maybe we should recommend the use of a standard font
- selector (like the UFSL) if one is available.
-
- Erlend.
-